Guide de la forge
Traduit de '''Guidance for Blacksmiths' Les membres de la forge sont cruciaux pour le succès d'Habitica. Vos contributions sont nécessaire et très appréciées ! Il y a plusieurs façon de contribuer du code pour le site et les applications mobiles. Le premier pas pour prendre connaissance de ce qu'il y a à faire est souvent de rejoindre la guilde Aspiring Blacksmiths (Habitica Coders) pour discuter de la programmation du site, apprendre quelques trucs et trouver des idées sur les éléments à coder. Pensez également à lire Installer Habitica localement pour trouver d'importantes informations de démarrage. Les différentes façon de contribuer Le site Web Vous trouverez ci-dessous des astuces pour trouver sur quoi travailler en fonction comment vous souhaitez contribuer. Dans tous les cas, pensez à vérifier le statut du problème remonté sur GitHub pour vous assurez que quelqu'un d'autre n'est pas déjà en train de le résoudre (si une pull request est liée, quelqu'un a déjà proposé une correction). Il est '''vivement recommandé' qu'avant de commencer votre travail, vous ajoutiez un commentaire sur le problème dans Github ou sur la carte Trello en indiquant votre intérêt à le résoudre et en demandant son statut actuel ; attendez ensuite un jour ou deux pour une réponse. En effet, certains problèmes et certaines fonctionnalités ne sont pas appropriées pour y travailler si l'équipe de développement d'Habitica est en train de faire des changements de grande envergure dans certaines parties du code qui pourraient régler ces points. Cela s'avère possible même lorsque le problème est identifié avec une des étiquettes ci-dessous. Si certaines personnes on déjà commenté récemment pour indiquer qu'ils travaillent sur un problème ou une carte Trello, laissez-les travailler dessus. Cependant, si plusieurs jours se sont écoulés depuis leur dernier commentaire, il se peut qu'elles n'aient plus le temps de contribuer, et vous pouvez légitimement demander s'il est possible de prendre la main sur le sujet. Avant de commencer à travailler sur un problème ou une fonctionnalité, vous pourriez vouloir décrire votre approche du sujet, afin que l'équipe de développement indique si celle-ci est appropriée. Regardez aussi les étiquettes GitHub utilisées par Habitica. * Je souhaite démarrer doucement : Vérifiez la liste des problèmes sur Github et cherchez ceux avec l'étiquette priority - minor, priority - medium, et entry level coding où vous pourrez demander à contribuer. * Je souhaite aider là où c'est le plus important : Vérifiez la liste des problèmes sur Github et cherchez ceux avec l'étiquette help welcome now, priority - critical, et priority - important et demandez à y contribuer avant de commencer. * Je souhaite créer des unités de tests et des tests de Karma : Merci de chasser les bugs ! Réferez-vous à la section Tests pour plus d'information. * Je souhaite construire des choses : Quelle volonté héroïque ! Vérifiez la liste des fonctionnalités dans Trello]. Il est important de d'abord vérifier sur une demande de fonctionnalité est approuvée par l'équipe de développement. Certaines suggestions de fonctionnalités ne sont pas prêtes pour une implémentation et la pull request pour la mettre en place ne serait pas acceptée. Application mobile pour iOS * Veuillez d'abord envoyer un mail à mobile@habitica.com pour voir avec l'équipe de développement mobile ce que vous souhaitez faire. * L'application "Habitica" pour iOS a son propre code et son propre dépôt GitHub sur github.com/HabitRPG/habitrpg-ios. Ce dépôt est open source et les contributions sont les bienvenues. * L'ancienne application iOS "HabitRPG" n'est plus développée et les contributions n'y seront pas acceptées. Application mobile pour Android * Veuillez d'abord envoyer un mail à mobile@habitica.com pour voir avec l'équipe de développement mobile ce que vous souhaitez faire. * L'application "Habitica" pour Android a son propre code et son propre dépôt GitHub sur https://github.com/HabitRPG/habitrpg-android github.com/HabitRPG/habitrpg-android. Ce dépôt est open source et les contributions sont les bienvenues. * L'ancienne application Android "HabitRPG" n'est plus développée et les contributions n'y seront pas acceptées. BountySource Certains problèmes ont des primes BountySource assignées, et mises en place par l'équipe de développement ou les utilisateurs et utilisatrices d'Habitica. Si votre correctif pour un tel problème est accepté, vous aurez le droit de réclamer la prime comme paiement. Dans tous les autres aspects, ces problèmes sont traités de façon identiques aux autres (sans primes) ; il est donc conseillé de respecter les points énoncés jusqu'à présent (par exemple d'abord demander avant de travailler sur un problème.) Stack technologique du site Les technologies utilisées par Habitica pour le site sont listées ci-dessous. Vous n'avez pas besoin d'être familier avec toutes celles-ci, ni même la plupart d'entre elles, pour contribuer. Quelques liens vers des dossiers d'apprentissage de grande qualité sont également inclus. Serveur Client Tester Services Changement d'API Le 21 Mai 2016, la version 3 de l'API d'Habitica a été livrée. La version 2 continuera à fonctionner jusqu'au 15 Juillet 2016, mais au delà, tout logiciel qui l'utilise cessera de fonctionner. Des informations à propos de la nouvelle API est disponible sur la page Application Programming Interface. Tout au long de Mai 2016, il y a eu un gel temporaire du code pour permettre à l'équipe de développement de se concentrer sur la phase finale de l'API v3. Ce gel est maintenant inactif, et toute contribution est à nouveau acceptée. Quelques points à noter : * La v3 de l'API fait maintenant partie de la branche de développement, donc toute contribution devrait se baser sur cette branche, comme c'était le cas avant le gel. * Avant de développer un nouveau code, votre installation locale devrait être mise à jour pour utiliser l'API v3. Voir les détails ci-dessous. * Vous pouvez choisir de travailler sur ce que vous voulez, mais les pull requests pour les corrections de bug seront vérifiées avant celles pour la plupart des nouvelles fonctionnalités. * Comme toujours, il est conseillé de d'abord demander sur le problème GitHub ou sur la carte Trello s'il est utile pour vous de travailler sur ce problème, pour vous assurer que vous ne perdez pas votre temps sur une modification qui ne pourra pas être acceptée. Les questions peuvent être posées sur la guilde Aspiring Coders. Les annonces importantes sur les changements de l'API peuvent également être trouvées sur The Forge, le blog de développement d'Habitica. Mettre à jour votre installation locale pour utiliser l'API v3 La version 3 de l'API a été fusionnée avec la branche develop, et est prête pour une utilisation en développement (voir néanmoins les points ci-dessus dans la section "Changements de l'API") Si vous disposez déjà d'une installation locale sous la version 2, il faudra l'ajuster pour qu'elle utilise l'API v3. Si vous utilisez Vagrant, il vous faudra détruire votre instance courante et en créer une nouvelle pour mettre à jour l'installation locale. Suivez les indications pour Installer Habitica localement et ignorez les étapes ci-dessous. Pour tous les autres types d'installations locales : * Effacez tous les cookies et les données en cache du navigateur pour localhost, afin d'éviter les conflits qui seraient causés par des données créées avec l'API v2. * Il est possible qu'il soit nécessaire d'ajouter de l'espace d'échange (swap). Si vous rencontrez des problèmes avec npm install ne fonctionnant pas, augmentez la taille le fichier de swap. Voir les "Notes importantes" dans Installer Habitica localement pour plus de détail. * Utilisez nodejs 4 avec nom 3. Si vous développiez pour Habitica avant que l'API v3 ne soit mise en place, vous aurez npm 2 d'installé, et il faudra mettre à jour vers npm 3. S'il vous faut utiliser une version différente de node ou de npm pour d'autres raisons, vous pouvez utiliser nvm pour gérer les versions. Si vous souhaitez complètement remplacer npm 2 par npm 3 et que vous utilisez Linux, vous pouvez utiliser la commande sudo npm install -g npm@3 * Mettez à jour le code source en utilisant les commandes git fetch et rebase comme d'habitude. (pendant les prochaines semaines, recommencez cette étape plusieurs fois par semaine, parce que le code sera changé régulièrement). * Supprimez website/public et tout son contenu (il a été renommé en website/client mais tout ne sera pas automatiquement supprimé par git, et si vous ne le supprimez pas, nodemon aura trop de fichiers à surveiller). * Comparez votre fichier config.json avec config.json.example et ajoutez les modification à votre propre fichier config.json (à refaire à chaque commande rebase). * Supprimez le répertoire node_modules, parce qu'il contient de nombreux modules périmésqui ne sont plus nécessaires. * Lancez npm install (il vaut mieux répéter cette commande à chaque rebase ; souvent, aucun nouveau module ne sera installé, ce qui en fera une action relativement rapide). * Il est possible que d'autres étapes soient nécessaires pour mettre à jour votre installation locale. Si vous rencontrez des problèmes, veuillez créer un problème dans GitHub. * Si vous avez connaissance d'autres actions nécessaire, merci de mettre à jour ces instructions ! Votre aide pour maintenir ce document à jour est la bienvenue ! Si vous n'avez pas la certitude que certaines actions soient nécessaires à toutes les personnes mettant à jour leur installation locale, vous pouvez quand même les ajouter ici en complétant par une note sur vos doutes. Travailler avec une installation locale Les membres de la forge devraient créer une instance locale fonctionnelle d'Habitica, pour les tests et le développement. L'installation de cette instance peut s'avérer difficile, c'est pourquoi nous avons rassemblé des astuces pour chaque système d'exploitation dans Installer Habitica localement. MongoDB Vous trouverez ci-dessous des astuces pour vous permettre de mieux comprendre la base de données Mongo. Dans les commandes ci-dessous, le symbole $ indique un prompteur de Shell Unix, windows ou Git, et le symbole > indique un prompteur de Shell Mongo. Ne tapez que le texte qui apparaît après $ ou > dans votre ligne de commande. Accéder & un shell Ouvrez le shell mongo et sélectionnez la base de donnée : $ mongo > show dbs > use habitrpg Vous pouvez également ouvrir directement le shell avec la bonne base de données : $ mongo habitrpg Utiliser le shell Voir les "collections" dans la base de données ("users", "groups", etc): > show collections Trouvez votre utilisateur de test et examinez ses données. Depuis le paramétrage localhost], copiez l'ID utilisateur et lancez la commande suivante : > db.users.find({_id: '85b007a2-b5b9-4bb4-8b82-e4567edb4919'})0 Vous ne souhaitez voir que les préférences ? > db.users.find({_id: '85b007a2...'})0.preferences Pour mettre à jour quelque chose pour votre utilisateur, utilisez la méthode update avec $set. Par exemple, modifier votre texte de profil : > db.users.update({_id: '85b007a2...'}, {$set: {'profile.blurb':'test'}}) Obtenir 10 gemmes (possible également depuis le menu de debug dans la partie droite du pied de page) : > db.users.update({_id: '85b007a2...'}, {$set: {'balance':10}}) Obtenir les droits d'administration (vous donnera accès à certaines options supplémentaires dans le Hall) : > db.users.update({_id: '85b007a2...'}, {$set: {'contributor': {'admin':1}}}) Obtenir des parchemins de quêtes non achetables (par exemple pour les quêtes en édition limitée) : > db.users.update({_id: '85b007a2...'}, {$set: {'items.quests': {"egg":2,"basilist":1,"evilsanta":1,"evilsanta2":1}}}) Cette commande vous donnera deux parchemins de Chasse aux oeufs et un parchemin de chaque pour trois autres quêtes. Veuillez noter que cela éliminera tous les autres parchemins que vous pourriez posséder. Les autres parchemins peuvent être ajoutés de la même façon (les clés respectives peuvent être trouvées dans common/script/content/index.js, mais ce fichier pourrait changer de nom bientôt à cause des modifications du code) ou peuvent être achetées au marché. Utiliser les scripts de debug Dans le répertoire debug-scripts (à la racine du dépôt), vous trouverez des scripts qui vous permettent de modifier les comptes de test de différentes façons. Pour trouver ce que fait chacun, lisez le code ou lancez le script en utilisant node sans paramètre pour voir le message d'usage. Par exemple : node ./debug-scripts/grant-all-mounts.js Créer un compte local identique à votre compte du site principal Exportez les données de votre avatar en utilisant la routine de l'API GET /user, et importez-la localement en utilisant des commandes MongoDB comme db.collection.insert(). Cela peut vous servir pour rapidement créer un compte local contenant plusieurs tâches, de l'équipement, de la monnaie et un inventaire. Votre compte devra être inséré dans la collection users, mais cette collection n'existera pas dans Mongo tant qu'au moins un compte sera créé sur votre installation locale. Pour cela, démarrez votre installation locale et créez un compte de test, puis importez votre compte de production. L'API n'exporte pas certaines informations d'authentification pour des raisons de sécurité, donc vous devrez les définir après avoir importé vos données. La commande ci-dessous définit votre mot de passe à "test" et créé un jeton d'API : > db.users.update({'auth.local.username': 'your-username'}, {$set: {'auth.local.salt': '7eff6ff32a', 'auth.local.hashed_password': '5b5d5f748091e62aadf2f109f4a7379d2d8653dc', 'apiToken': '48ed9d70-0adf-431d-a001-1cb12d57590e'}}); Attention ! N'utilisez pas le même jeton d'API ou mot de passe que celui utilisé pour votre compte principal ! Dans le cas où vous auriez besoin d'aide pour votre installation locale ou si vous devez soumettre des informations de celle-ci, vous aurez probablement besoin d'inclure toutes les données d'authentification. Si celles-ci sont identiques à celles de votre compte principal, la sécurité de ce dernier serait compromise. Le token utilisé dans l'exemple ci-dessus a été généré aléatoirement, et peut être utilisé sans problème sur votre installation locale. Migrations Certains changements sur le site Habitica demandent des modifications (par exemple assigner une valeur par défaut à un nouveau paramètre pour tous les comptes). De tels changements sont réalisés avec des scripts de migration, qui utilisent Javascript pour se connecter à la base de données et faire les modifications. tous les scripts de migration sont dans migrations/. Lisez-les et utilisez-les comme exemple pour écrire vos propres scripts. les scripts modifiés récemment sont plus propices à contenir du meilleur code, plus à jour que les anciens scripts. Pour tester un script de migration : $ mongo habitrpg migrations/name_of_script.js Astuces et bonnes pratiques Angular/Node/Pug Formatage et qualité du code Respectez les standards de rédaction déjà en place dans le code (par exemple, deux espaces pour chaque niveau d'indentation). Nous utilisons lint pour assurer un formatage cohérent du code. Si vous soumettez une pull request, une série de tests automatiques vérifieront votre code et bloquera si lint trouve des problèmes. Ces tests doivent être validés pour que votre code puisse être accepté. Liaisons de données et modèles conditionnels Lorsque vous travaillerez avec des modèles Pug, il se peut que vous voyiez des attributs d'éléments comme ng-class, ng-show ou ng-if. Il s'agit de liaisons utilisées pour rattacher des modèles de données à l'affichage dépendant d'AngularJS. Ces liaisons peuvent être utilisées pour définir des styles ou des éléments d'affichage à partir de conditions. Il se peut également que vous rencontriez d'autres attributs comme bo-class ou bo-if... Quelle différence ? Les liaisons qui commencent par "ng" font partie d'Angular et sont complètement dynamiques. Cela signifie qu'à chaque fois que quelque chose change dans l'application, Angular testera ces liaisons par rapport aux conditions et le mettra à jour. Cela joue de façon évidente sur les performances. Parfois, la donnée utilisée pour calculer ces conditions ne changera pas souvent, voir pas du tout. Dans ce cas, nous avons une option pour les liaisons statiques, en utilisant une bibliothèque nommée Bindonce. Ces liaisons sont similaires, mais ne sont vérifiées qu'au chargement initial de l'application. Cette méthode est à préférer pour les données qui ne changeront pas. Les directives Bindonce ne devraient être utilisées que lorsque le modèle de données utilisé pour les condition ne changera pas pendant une session, ou changera si peu qu'il n'est pas déraisonnable de s'attendre à ce que la page soit rechargée. Si ce n'est pas le cas, tenez-vous en aux liaisons traditionnelles. Si vous ne savez pas ou ne pouvez pas décider, utilisez simplement l'attribut ng-. Textes traduisibles (fichiers de localisation) Ajouter une chaîne traduisible Pour ajouter une nouvelles chaîne traduisible ) un modèle, il vous faudra l'écrire dans le fichier Pug comme suit : env.t("nouvelleReference") Puis, dans le répertoire common/locales/en, modifier les fichiers json pour ajouter une nouvelle chaîne de la façon suivante : 'derniereReference': 'Ajoutez une virgule à la fin de la ligne', 'nouvelleReference': 'Nouveau texte à traduire' } Ne mettez pas à jour les fichiers dans les autres répertoires de common/locales ; les traductions sont gérées par Transifex. Pour tester la chaîne : * arrêtez npm s'il est en marche (Ctrl-C) * lancez npm start Modifier des chaînes traduisibles Les chaînes traduisibles sont contenues dans des fichiers, dans le répertoire common/locales/en. Chaque chaîne consiste en une clé et un texte, par exemple : 'clearAll': 'clear all items', Ne changez pas la clé sans une très bonne raison de le faire. Changer le texte d'une chaîne traduisible est possible, mais les clés peuvent être référencées ailleurs dans le code d'Habitica. Si la clé est modifiée à un endroit, tous les autres endroits où elle est utilisée doivent être changés également. Par exemple : si vous devez changer le texte 'clear all items' en 'delete all items', vous ne devriez pas changer 'clearAll' en 'deleteAll'. Par ailleurs, les clés utilisées dans les chaînes traduisibles anglaises sont également utilisées dans tous les autres répertoires de langages situés dans common/locales. Lorsqu'un texte est modifié sans que la clé ne le soit, l'autre langage continuera d'utiliser la traduction existante pour le nouveau texte anglais, jusqu'à ce que les personnes réalisant la traduction aient le temps de les mettre à jour. Généralement, c'est le comportement recherché, car les traductions existantes sont toujours suffisamment correctes pour être utilisées. Cependant, si vous changiez la clé tout comme le texte, toutes les traductions existantes ne seraient pas utilisée parce que le fichier traduit ne contiendrait pas encore cette nouvelle clé. Cela signifierait que les personnes utilisant un langage différent de l'anglais verraient le nouveau texte en anglais jusqu'à ce que la traduction ait été réalisée pour la nouvelle clé. Tests Habitica a une série de tests qui peuvent être lancés manuellement ou automatiquement pour aider à détecter les bugs. Lorsque l'équipe de développement d'Habitica déploie une nouvelle version du site en production, le processus de déploiement lance ces tests et bloque le déploiement si au moins un des tests retourne un résultat négatif. Avant de faire une pull request, il est recommandé que vous lanciez tous les tests existants pour vous assurer que vous n'avez pas introduit d'erreur. Si vous n'arrivez pas à lancer ces tests, faites quand même la pull request. Travis CI est utilisé pour lancer tous les tests sur chaque pull request. Si le un test rate, Travis rapportera le résultat dans votre pull request et donnera un lien que vous pourrez utilisé pour voir le code de sortie du test. Si l'échec du test est imputable à votre code, il vous faudra le changer avant que votre code ne soit intégré. Parfois, des tests échoueront pour des raisons indépendantes à votre code. En cas de doute, vous pouvez poser une question dans les commentaires de la pull request. La plupart de code votre code devrait avoir des tests de prévus avant qu'il ne soit inclus dans l'ensemble du code d'Habitica. Pour autant, l'équipe de développement d'Habitica vous aidera à écrire ces tests, ou --si le temps le permet-- l'écrira pour vous si vous ne pouvez pas le faire. N'ayez pas peur de soumettre une pull request sans tests, surtout si vous avez des doutes sur ce qu'implique le processus de test, mais soyez conscient que votre code pourrait ne pas être accepté tant que les tests ne sont pas écrits par vous ou l'équipe de développement. Avant de lancer un test ou l'ensemble des tests sur votre installation locale, suivez ces différentes étapes : # Installez gulp si ce n'est pas déjà fait, en utilisant npm install -g gulp. Vous pouvez lancer cette commande si vous n'avez pas la certitude que gulp est installé. # Assurez-vous que mongod est lancé. # Arrêtez tous les autres processus, comme npm start, ou n'importe quel autre processus qui est déjà en train d'effectuer un test. N'essayez pas de lancer deux tests simultanément. # Lancez killall node. Cette étapes n'est pas systématiquement nécessaire, mais si vous avez récemment lancé des test et essayez de le lancer à nouveau, vous pourriez voir des erreurs comme "before all" hook: callee$2$0 et Error: connect ECONNREFUSED. Arrêter tous les processus node éliminera ces erreurs. # Replacez-vous au répertoire racine de votre installation locale. Pour lancer l'ensemble des tests localement : # Lancez npm test, qui est un alias pour node_modules/.bin/gulp test, qui lui-même prépare l'environnement de test et lance toute la suite de tests. Pour lancer un seul test : # Lancer gulp test:nodemon dans un terminal de session. # Attendez le retour info: Connected with Mongoose et laissez le tourner. # Dans un autre terminal de session, lancez mocha test/SOUS_REPERTOIRE/NOM_DU_TEST.js Pour lancer tous les tests d'un sous-répertoire : # Lancer gulp test:nodemon dans un terminal de session. # Attendez le retour info: Connected with Mongoose et laissez le tourner. # Dans un autre terminal de session, lancez mocha test/SOUS_REPERTOIRE --recusive Pour lancer les tests sur le frontal : * Lancez npm run test:karma Pour lancer les tests de lint : * Lancez npm run lint Pour plus d'information à propos des tests d'API, lisez So you want to write API integration tests? Les tests avec Vagrant Si vous lancez les tests dans Vagrant, vous pourriez voir ces erreurs : Error: /vagrant/.eslintrc: Configuration for rule "func-style" is invalid: Value "2,declaration,Object" has more items than allowed. Ou plusieurs exemplaires de celles-ci : 1:1 error Definition for rule 'no-empty-pattern' was not found* no-empty-pattern 1:1 error Definition for rule 'no-arrow-condition' was not found no-arrow-condition Il se peut aussi que ce test démarre mais ne termine jamais : Starting 'test:e2e:safe'... Une correction propre pour ces problèmes sera bientôt documentée ici, mais en attendant, vous pouvez éviter ces problèmes en modifiant deux fichiers à la racine de votre installation locale. * Modifiez .eslintrc pour commenter ces lignes : ** "no-empty-pattern": 2, ** "no-arrow-condition": 2, ** "func-style": "declaration", { "allowArrowFunctions": true }, * Modifiez tasks/gulp-tests.js pour commenter ces lignes : ** 'test:e2e:safe', Ne faites pas de commit sur ces lignes, elles sont nécessaire pour lancer les tests sur le serveur. Les images Pour toute information sur la création de nouvelles images pour Habitica, lisez le Guide des mosaïstes. Lorsqu'une nouvelle image a été préparée et approuvée par l'équipe de développement, un problème sera créé sur GitHub pour demander son ajout dans Habitica. La personne qui prendra en charge ce problème devra alors l'ajouter dans le dépôt. La plupart des images devront être copiées dans le sous-répertoire correspondant dans common/img/sprites. Après avoir ajouté les nouvelles images ou les nouvelles version d'images existantes, lancez npm run sprites pour recompiler le classeur d'images. Parfois, cette commande créera un nouveau classeur d'images, auquel cas vous pouvez utiliser git add pour ajouter le nouveau fichier. Vous les trouveres dans common/dist/sprites (cherchez un fichier *.png et un autre *.css pour chaque classeur). Autres commandes utiles Voici quelques commandes utiles. Chercher dans le code Dans la console, tapez : grep -R "CHAINE" * pour chercher CHAINE dans tous les fichiers du répertoire courant et tous les sous-répertoires qu'il contient. Pour faire une recherche insensible à la casse (CHAINE ou Chaine ou chaine etc), ajoutez '-i' : grep -iR "CHAINE" * Vous aurez souvent besoin de chercher tous les fichiers contenant un mot-clé, afin de déterminer quel fichiers doivent être modifiés pour ajouter/changer une fonctionnalité. La commande grep peut aussi prendre un regex comme paramètre : grep -R "REGEX" * Plus d'information sur grep et les regex ici. Chercher et remplacer Voici une commande perl à lancer dans un terminal : perl -e "s/SOURCE/CIBLE/g" -pi $(find . -name "*.js") Remplacer SOURCE par la chaîne que vous voulez remplacer et CIBLE par celle qui doit la remplacer. Note : cet exemple remplacera cette chaîne Seulement dans les fichiers Javascript (extension .js), mais vous pouvez spécifiquer un autre type de fichier si vous le voulez. Si vous voulez remplacer toutes les chaînes, mais pas leurs pluriels ou d'autres mots contenant cette chaîne (par exemple remplacer arme par TEST, mais ne pas remplacer armes), lancez la commande : perl -e 's/arme\b/TEST/g' -pi * Si vous voulez supprimer toutes les lignes des fichiers javascript qui contiennent un mot-clé, lancez : perl -ni -e 'print unless /keyword/' -pi $(find . -name "*.js") Ces commandes sont particulièrement utiles pour les modifications liées aux traductions. Tester l'interface d'API Swagger localement Habitica a une interface d'API, qui utilise la base de données et le code de production. Lorsque vous avez fini d'installer localement Habitica, vous pouvez tester la version locale de l'interface sur http://localhost:3000/static/api Si votre version de config.json a été créé il y a longtemps et vous n'avez pas toutes les données à jour de config.json.example, vous pourriez avoir besoin de modifier config.json pour changer la ligne BASE_URL en "BASE_URL":"http://localhost:3000", puis arrêter et relancer la commande npm start. Paramétrage des préférences Habitica possède plusieurs paramétrages de préférences pour que chacun personnalise le comportement du site. De nouveaux paramètres peuvent être ajoutés si nécessaire. Veuillez ne pas ajouter de paramètre que seul un petit nombre de personnes seraient susceptibles d'utiliser, ou des paramètres pour des personnalisations futiles. Choisissez plutôt des comportements que la majorité des utilisateurs aimeront probablement. Trop de préférences rend l'écran de paramétrage plus complexe et visuellement embrouillé. En cas de doute sur l'utilisation d'une préférence ou non, vous pouvez en discuter sur la guilde Aspiring Coders ou sur le problème GitHub ou la pull request correspondant. Astuce pour stocker les préférences Quand une nouvelle préférence est nécessaire, elle peut être ajoutée dans website/src/models/user.js. Généralement, la base de donnée le récupèrera automatiquement et l'ajoutera sur chaque compte si nécessaire. Si la base de données doit être mise à jour manuellement, l'équipe de développement peut le réaliser. Les sections "Information de développement" dans les pages générales du Wiki A la fin de certaines pages du wiki, vous pourrez trouver des sections appelées Informations de développement. Elles contiennent des astuces utiles au développement par rapport au sujet de la page. Ces informations sont cachées par un bouton montrer/cacher afin de ne pas encombrer une page pour les autres personnes. Ces sections utilisent les modèles et pour s'assurer du formatage et la syntaxe des boutons et des autres textes. Pour voir comment cela est réalisé, ouvrez une page possédant cette section avec l'éditeur source. Pour voir une liste de toutes les pages avec cette section, utilisez l'outil "What links here" pour le modèle 'Start'. Pour rendre toutes les sections "Informations de développement" visibles par défaut : * Créez un compte Wikia si vous n'en avez pas déjà un. * Modifiez votre fichier css Wikia personnel, situé sur http://habitica.wikia.com/wiki/User:YOUR_USERNAME_HERE/wikia.css * Insérez ces deux lignes dans le fichier : /* Force la visibilité des sections "Informations de développement" */ .habitrpg-InfoForDevs { display:block !important; } .habitrpg-InfoForDevs-hideIfDev { display:none; } Vous pouvez en voir un exemple sur User:LadyAlys/wikia.css Paliers de contribution Vous avez de la chance ! Contribuer du code ne nécessite rien de spécial, comme remplir une requête de palier de contribution, afin de vous rapporter un palier. Ces paliers de contribution seront accordés par l'équipe de développement au fur et à mesure qu'elle intègre le nouveau code. L'équipe tracera vos contributions pour ajouter à chaque palier. Les premiers paliers de contribution sont assez simples à obtenir et vous verrez qu'une seule pull request peut suffire pour chacun. Les paliers suivant vont nécessiter de plus en plus de travail et plusieurs pull requests pourraient s'avérer nécessaire. L'équipe de développement gardera trace de chacune et accordera le palier lorsqu'il y en aura eu assez. en:Guidance for Blacksmiths Catégorie:Contribuer